Improve software exception handling performance #108480

janvorli · 2024-10-02T12:30:37Z

I have recently discovered that large part of the time spent in the EH while handling software exception is in the RtlLookupFunctionEntry Windows API. That API is called when unwinding native (non-managed) frames on stack. The current implementation of the IL_Throw JIT helper that is used to throw managed exceptions needs three unwinds to get to the managed caller. Due to the two passes of EH, it means there are six calls made to that API per throw.
This change reduces that to just a single unwind, which leads to about 12% improvement in single threaded scenarios and about 30% improvement in multi-threaded one for a case when an exception is thrown over 10 managed frames and then caught on Windows. It also leads to similar improvements in async exception handling performance. I have also run the dotnet/performance EH tests and they have shown the same improvements.

An additional benefit of this change is removal of the helper method frame from IL_Throw and IL_Rethrow, which contributes to the current effort of getting rid of the helper method frames.

In a follow up change, I am planning to make similar change to the FCThrow helper and its variants, further reducing the usage of the helper method frames.

I have made this change for the new EH only.

jkotas · 2024-10-02T12:59:46Z

I am planning to make similar change to the FCThrow helper and its variants,

This should not be needed. We are working on deleting FCThrow.

jkotas · 2024-10-02T13:09:11Z

src/coreclr/vm/excep.cpp

+#ifndef DACCESS_COMPILE
+//
+// Init a new frame
+// funcCallDepth: the number of frames to skip when looking for the return address.


Typo: funCallDepth vs. funcCallDepth

Do we need this argument at all? It is always 1.

This will be passed in > 1 for the follow up change that will modify FCThrow to use this new way

You do not need to worry about FCThrows. They will be gone soon.

cc @AaronRobinsonMSFT

Ah, I have missed your comment on the plan to remove the FCThrow helpers. Then I can simplify it.

src/coreclr/vm/fcall.h

janvorli · 2024-10-02T13:14:56Z

I've also measured the performance improvement on Linux under WSL2 on the same machine where I've ran the Windows test. The single threaded results are exactly the same as the ones on Windows, but for multi-threaded case, this change improves the performance 3 times! The same is true for multi-threaded async EH.

jkotas · 2024-10-02T13:16:15Z

src/coreclr/vm/fcall.h

+#define FC_CAN_TRIGGER_GC_HAVE_THREAD(thread)
+#define FC_CAN_TRIGGER_GC_HAVE_THREADEND(thread)


Suggested change

#define FC_CAN_TRIGGER_GC_HAVE_THREAD(thread)

#define FC_CAN_TRIGGER_GC_HAVE_THREADEND(thread)

These are debug-only macros. We do not need special optimized variants that take Thread*.

(Also, passing around current Thread* mattered a lot before current thread getter was converted to a regular thread static. It matters a lot less now.)

Also, passing around current Thread* mattered a lot before current thread getter was converted to a regular thread static. It matters a lot less now

I have measured a noticeable difference in perf when the GetThread was called multiple times in the IL_Throw.

These are debug-only macros. We do not need special optimized variants that take Thread*.

Ok, makes sense

~~Hmm, they are actually not debug only, they are defined as empty for !ENABLE_CONTRACTS~~ Right, the contracts are debug only.

I have measured a noticeable difference in perf when the GetThread was called multiple times in the IL_Throw.

GetThread should be just a couple of instructions and the C++ compiler should be able to CSE redundant calls. I would not expect that we are at the point where a couple more instructions in IL_Throw makes a noticeable difference.

Hmm, they are actually not debug only, they are defined as empty for !ENABLE_CONTRACTS

ENABLE_CONTRACTS == DEBUG

jkotas · 2024-10-02T13:17:50Z

src/coreclr/vm/fcall.h

@@ -799,6 +799,22 @@ LPVOID __FCThrowArgument(LPVOID me, enum RuntimeExceptionKind reKind, LPCWSTR ar
 #define HELPER_METHOD_FRAME_GET_RETURN_ADDRESS()                                        \
    ( static_cast<UINT_PTR>( (__helperframe.InsureInit(NULL)), (__helperframe.MachineState()->GetRetAddr()) ) )

+#define EXCEPTION_METHOD_FRAME_BEGIN(funCallDepth) \


I do not think this needs to be wrapped in a macro. Inlining the code to two places where it is needed would be more readable.

This will be used in more places with the follow up changes - in the FCThrow variants.

Again, I've missed your comment on the fact that FCThrow will go away. I am not sure what the plan is though. For example, the JIT_Div throws uses the FCThrow when there is division by zero or overflow. And there are other throwing helpers like JIT_ThrowMethodAccessException, JIT_ThrowFieldAccessException. And also some throw helpers that are QCALLs now ExceptionNative_ThrowEntryPointNotFoundException that I think could also get this improvement.

For example, the JIT_Div throws uses the FCThrow when there is division by zero or overflow.

We will convert them into the mix of C#, FCalls without HMF, and QCalls as needed. For example, check #102129 that converted multiplication helpers that followed very similar pattern.

And also some throw helpers that are QCALLs now ExceptionNative_ThrowEntryPointNotFoundException that I think could also get this improvement.

Any QCall can throw exception. If we were to improve something about QCalls, it should be a scheme that applies to all QCalls. My preference would be switch QCalls to an ordinary exception marshalling scheme (ie it is what code outside runtime needs to do to marshal exceptions between managed/unmanaged): store the exception on the unmanaged side in thread-local storage and rethrow it on the managed side.

If we care enough about improving perf of specific exception-throwing QCalls, we should just move more of them to C#. There is no point in throwing C++ exception, catching it, and rethrowing it as managed exception. We can throw the managed exception directly from managed code.

Ok, makes sense, so I have expanded the macros to the two locations they were used in in my last commit.

jkotas · 2024-10-02T13:38:32Z

This change reduces that to just a single unwind,

I am wondering what it would take to get rid of the one remaining unwind. It would require asm helper, but we have that asm helper for native AOT already. Can we re-use it (maybe with some ifdefs for now) to get rid of the one remaining unwind?

We are likely going to share some of the native AOT asm helpers with CoreCLR to get some of the HMFs.

janvorli · 2024-10-02T15:57:36Z

I am wondering what it would take to get rid of the one remaining unwind.

I think it should not be difficult. The asm helper would likely be quite different from the NativeAOT one though, so it doesn't seem like it would make sense sharing it. I'll try to make such change, but I'd prefer doing it as a separate change.

I have recently discovered that large part of the time spent in the EH while handling software exception is in the RtlLookupFunctionEntry Windows API. That API is called when unwinding native (non-managed) frames on stack. The current implementation of the IL_Throw JIT helper that is used to throw managed exceptions needs three unwinds to get to the managed caller. Due to the two passes of EH, it means there are six calls made to that API per throw. This change reduces that to just a single unwind, which leads to about 12% improvement in single threaded scenarios and about 30% improvement in multi threaded one for a case when an exception is thrown over 10 managed frames and then caught. It also leads to similar improvements in async exception handling performance. An additional benefit of this change is removal of the helper method frame from IL_Throw and IL_Rethrow, which contributes to the current effort of getting rid of the helper method frames. In a follow up changes, I am planning to make similar change to the FCThrow helper and its variants, further reducing the usage of the helper method frames. I have made this change for the new EH only.

janvorli · 2024-10-03T15:38:21Z

It seems like I've broken something while making the changes based on the PR feedback

jkotas

LGTM!

janvorli · 2024-10-03T23:59:15Z

/azp run runtime-coreclr outerloop gcstress0x3-gcstress0xc

azure-pipelines · 2024-10-03T23:59:21Z

No pipelines are associated with this pull request.

janvorli · 2024-10-04T00:00:37Z

/azp run runtime-coreclr outerloop, runtime-coreclr gcstress0x3-gcstress0xc

azure-pipelines · 2024-10-04T00:01:46Z

Azure Pipelines successfully started running 2 pipeline(s).

* Improve software exception handling performance I have recently discovered that large part of the time spent in the EH while handling software exception is in the RtlLookupFunctionEntry Windows API. That API is called when unwinding native (non-managed) frames on stack. The current implementation of the IL_Throw JIT helper that is used to throw managed exceptions needs three unwinds to get to the managed caller. Due to the two passes of EH, it means there are six calls made to that API per throw. This change reduces that to just a single unwind, which leads to about 12% improvement in single threaded scenarios and about 30% improvement in multi threaded one for a case when an exception is thrown over 10 managed frames and then caught. It also leads to similar improvements in async exception handling performance. On Linux, the multi-threaded gain is much higher, I've measured 3 fold improvement. An additional benefit of this change is removal of the helper method frame from IL_Throw and IL_Rethrow, which contributes to the current effort of getting rid of the helper method frames. I have made this change for the new EH only.

EgorBo · 2024-10-10T16:20:55Z

@janvorli quite a few improvements in dotnet/performance, nice

janvorli added the area-ExceptionHandling-coreclr label Oct 2, 2024

janvorli added this to the 10.0.0 milestone Oct 2, 2024

janvorli requested a review from jkotas October 2, 2024 12:30

janvorli self-assigned this Oct 2, 2024

jkotas reviewed Oct 2, 2024

View reviewed changes

src/coreclr/vm/fcall.h Outdated Show resolved Hide resolved

jkotas reviewed Oct 2, 2024

View reviewed changes

janvorli added 4 commits October 3, 2024 15:11

Fix missing semicolon and remove FC_CAN_TRIGGER_GC_HAVE_THREAD

16482dc

Remove funCallCount argument

fca2de1

Expand the macros for exception frames in place

f941262

janvorli force-pushed the improve-software-eh-performance branch from 9559a8a to f941262 Compare October 3, 2024 13:13

Fix macOS case when libunwind doesn't support context pointers

4a24e93

jkotas approved these changes Oct 3, 2024

View reviewed changes

jkotas added the tenet-performance Performance related issue label Oct 3, 2024

janvorli merged commit 1fa1745 into dotnet:main Oct 4, 2024
156 of 158 checks passed

EgorBo mentioned this pull request Oct 10, 2024

[Perf] Linux/arm64: 20 Improvements on 10/4/2024 11:21:53 AM dotnet/perf-autofiling-issues#42892

Closed

jkotas mentioned this pull request Oct 22, 2024

Move arithmetic helpers to managed code #109087

Open

am11 mentioned this pull request Oct 25, 2024

Remove MethodDesc::GetSig #109211

Merged

github-actions bot locked and limited conversation to collaborators Nov 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve software exception handling performance #108480

Improve software exception handling performance #108480

janvorli commented Oct 2, 2024

jkotas commented Oct 2, 2024

jkotas Oct 2, 2024

janvorli Oct 2, 2024

jkotas Oct 2, 2024

jkotas Oct 2, 2024

janvorli Oct 2, 2024

janvorli commented Oct 2, 2024

jkotas Oct 2, 2024

janvorli Oct 2, 2024

janvorli Oct 2, 2024

janvorli Oct 2, 2024 •

edited

Loading

jkotas Oct 2, 2024

jkotas Oct 2, 2024

jkotas Oct 2, 2024

janvorli Oct 2, 2024

janvorli Oct 2, 2024

jkotas Oct 2, 2024

janvorli Oct 3, 2024

jkotas commented Oct 2, 2024

janvorli commented Oct 2, 2024

janvorli commented Oct 3, 2024

jkotas left a comment

janvorli commented Oct 3, 2024

azure-pipelines bot commented Oct 3, 2024

janvorli commented Oct 4, 2024

azure-pipelines bot commented Oct 4, 2024

EgorBo commented Oct 10, 2024

		#define FC_CAN_TRIGGER_GC_HAVE_THREAD(thread)
		#define FC_CAN_TRIGGER_GC_HAVE_THREADEND(thread)

Improve software exception handling performance #108480

Improve software exception handling performance #108480

Conversation

janvorli commented Oct 2, 2024

jkotas commented Oct 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janvorli commented Oct 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janvorli Oct 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas commented Oct 2, 2024

janvorli commented Oct 2, 2024

janvorli commented Oct 3, 2024

jkotas left a comment

Choose a reason for hiding this comment

janvorli commented Oct 3, 2024

azure-pipelines bot commented Oct 3, 2024

janvorli commented Oct 4, 2024

azure-pipelines bot commented Oct 4, 2024

EgorBo commented Oct 10, 2024

janvorli Oct 2, 2024 •

edited

Loading